I didn't think committing all of the output files was the best way to do things

Claimed Leaderboard:

Unclaimed Leaderboard:

@Keyrxng

1. I tried running yarn dune, yarn issue and yarn userTx for my own address only for the ubiquity/ubiquity-dollar repo which generated the necessary json files (as expected). Then I ran yarn all which keeps throwing an error this should not happen. There's no such string/error in the codebase so it seems that this error is produced by some package.
2. Pls create your own supabase instance, run these migrations, uncomment these lines and make sure the permits are saved in a DB as expected.

1. This stumped me for a bit too but it's inside the WebSocketProvider class, why it's happening exactly has eluded me, it's difficult to catch but I will spend more time on pinpointing the cause, it does appear innocent from what I've seen.

 this.websocket.onmessage = (messageEvent: { data: string }) => {
    const data = messageEvent.data;
    const result = JSON.parse(data);
    if (result.id != null) {
      ...
        } else {
            let error: Error = null;
            if (result.error) {
            } else {
                error = new Error("unknown error");
            }
        }
    } else if (result.method === "eth_subscription") {
        // Subscription...
    } else {
        console.warn("this should not happen");
    }
};

2. I will give that a try and let you know, I've setup with the first already but I don't recall running the second migration

@rndquu what should be done

• add DAI into the tokens table with id 2
• update constants.ts with key and url
• run the three parsers
• run yarn all

Because it first fetches and filters the current DB it can be re-run any number of times and it'll populate the DB only with newly found permits, so it would be an effective solution for ubiquity/audit.ubq.fi#12 that would be gas free and there is far more data available to improve things further like pinning permits to issues etc. Thankfully actions can support the length of time it takes to run this collection of scripts so this could either be a standalone cron wf or converted into a plugin.

I had to be explicit with the row ids because it was trying to insert with single figure IDs automatically without defining them when the highest is 111 rn, I'm not sure if that's going to be a problem in other codebases.

The claimed vs unclaimed, I didn't want to jump to conclusions with things but we do need to consider that multiple permit comments is not an uncommon thing. Neither is the comment being quoted, especially by pav and both of these things would produce duplicate counts. Then there are the permits that are buried out there that are actually unspent.

I went through the unspent-permits.json for my own address and it found two for me (likely both participation rewards looking at the amount) I just claimed. Until we deal with all of those unspent permits this is the best things are getting I think.

@rndquu what should be done

• add DAI into the tokens table with id 2
• update constants.ts with key and url
• run the three parsers
• run yarn all

Because it first fetches and filters the current DB it can be re-run any number of times and it'll populate the DB only with newly found permits, so it would be an effective solution for ubiquity/audit.ubq.fi#12 that would be gas free and there is far more data available to improve things further like pinning permits to issues etc. Thankfully actions can support the length of time it takes to run this collection of scripts so this could either be a standalone cron wf or converted into a plugin.

I had to be explicit with the row ids because it was trying to insert with single figure IDs automatically without defining them when the highest is 111 rn, I'm not sure if that's going to be a problem in other codebases.

The claimed vs unclaimed, I didn't want to jump to conclusions with things but we do need to consider that multiple permit comments is not an uncommon thing. Neither is the comment being quoted, especially by pav and both of these things would produce duplicate counts. Then there are the permits that are buried out there that are actually unspent.

I went through the unspent-permits.json for my own address and it found two for me (likely both participation rewards looking at the amount) I just claimed. Until we deal with all of those unspent permits this is the best things are getting I think.

This is where I had left things. The script just needs ran by a someone with access to the core DB. They need to add another token as-of when I last touched this.

Would you guys prefer that I "re-open" this and spend a day or so trying to improve it further, or are we happy to go ahead or what should we do with this PR exactly?